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These comments are relative to the July 22 Janus Functional Specification. Many points 
have been covered in a number of other memos. Let me try to list some that may not have 
been covered. Sorry that these comments did not get to you sooner, but 1 have had a hard 
time getting responses collected from my section. I will summarize most of the comments 
and then attach three writeups from my people that you may not have seen yet. (These 
cover many detailed points.) 

"D iscussion Required" Item s 

1. In its present form, I do not see how this product can span the whole range of users — 
from unsophisticated users doing letter or short memo writing to those editing complex 
technical or business documents or doing page layout. It is too rich and complex for the 
simple user— especially the abstractions of option sheets. That is, a sophisticated user 
can use the system to do simple things, but a simple user may be completely lost 
Several other suggestions have been made to try to improve this area— and the document 
does do many good things in this regard. Maybe a revised version v/ill solve all this. 
But 1 question the idea that one "universal" editor can serve all users. It has never 
worked before. Icons might help, but maybe not totally. It still may be necessary to 
"package" this as several different "application" packages, with increasing levels of power 
and sophistication. 

2. There are many comments on file naming. (See the memo from Kimball, item #3; 
Bishop memo; Redell memo; Burr memo.) Basically these all ask: 

a. Should string names be unique? 

b. String names vs. icons 

c. Multiple index (name) fields versus single (unique) names 

d. Versions or other modifiers 

e. Cataloging dismounted volumes 

f. Naming of remote files (over the Xerox wire) 

3. The question of filing on the floppy disk versus a future rigid disk generates a lot of 
potential issues. For example: 

a. What does it do to performance or allowable file size to "promote" files from a 
user floppy to a system floppy? Why not have this only as an option, not a 
standard? Why force always copying files, since they are not updated in place 
anyway? 
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b. Why make the decision about "edit" or "view" when starting to work on a file? 
Why not make it after looking at or editing a file— i.e. by then saving what was 
done, or not? 

c. Would we catalog dismounted files or file drawer with a rigid-disk-based system 
but not a floppy-based system? 

d. What does "protected" status mean on a floppy? If it contains sensitive data, just 
keep the floppy physically secure. It seems unnecessarily complex to try to 
protect some document but not others in a floppy based file drawer. (A Janus 
"B" or rigid-disk based system will have different protection needs, however.) 

e. What sorts of messages appear to the user if his files don't fit on the scratch 
space on the system floppy? On a user floppy (after updating)? 

f. What is the effect of these file structures on UNDO or REPLAY? 

4. The whole question of storage media other than standard OIS floppy is not covered. 

a. What about tape cassettes? 

b. What about magnetic cards? 

c. What about Troy floppies? 

d. What about IBM (OS-6) floppies? 

5. What happens to the function keys in an IAS based application? For business control vs 
editing in general? This is one of the reasons to reduce the number of function keys. 

6. Should the functional specification contain reasons or rationale for wA;^ some things are 
done this way? This document should help "sell" these concepts; or is there another 
document to do that? 
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